Carrying out software authorization is basically known from the prior art. This may be performed, for example, by inputting appropriate license keys, or in a recurring manner via challenge response protocols. At a location in the program code, a value which has been encrypted using a cryptographic method is transmitted to an external module, the internal computing sequences of which the user of the application does not have access; the user is able to observe only the input and output data. The external module, which has the corresponding cryptographic algorithms, decrypts the value, performs certain operations on the plaintext, and returns the encrypted result to the actual program code. When the actual program code receives the correct result, the further instructions in the program code are correctly executed. If the result is incorrect, i.e., it has been manipulated from the outside, or no result at all is returned, for example, the software fails to run properly or is blocked. Such external modules may be formed by USB dongles or smart cards, for example.
In the method described above, the communication with the external module results in latency in the program sequence. This makes it impossible to integrate the authorization process not only into performance-critical program functionalities, but also into functionalities which are used frequently or with a certain continuity by the user of the application, since interfering delays in the program flow or in operating the application would otherwise occur. This is particularly true when the external module is not directly connected, but instead is linked to the program or the corresponding data processing unit via possibly faulty communication means. Thus, a compromise between security and performance is usually made when challenge response protocols are used, even if integration of the authorization process into essential base functionalities would improve the quality of protection.
In addition, in this type of method it is usually not possible to securely control the sequence or the frequency of the authorization, or to import or change statistical parameters which control the probability or frequency of carrying out the authorization processes. If such a change to the actual program or the program portion responsible for the authorization is made possible, this often provides an easy opportunity for manipulation from the outside, and thus represents a significant security risk for protection of the program sequence.
Furthermore, the use of an external module represents a large outlay in materials, costs, and administrative effort. Centralization of external modules, for example via a server on the Internet, is therefore desirable.